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ABSTRACT 



A graphical control system for automatically generating 
application program shell code in an object-oriented system. 
The graphical control system allows a \iser to easily enter 
object information and associated control information in a 
single graphical user, interface. The system automatically 
generates application shell code according to the operating 
system environment in which the system is running and the 
user entered object and object control information. The 
invention eliminates the need to program in or edit control 
application code by hand for each object defined in the 
apphcation. Also, the control code for each object is directly 
associated with the object during construction and therefore 
is created in the same desired location as that of the object 
data. 

27 Claims, 31 Drawing Sheets 
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METHOD AND APPARATUS FOR CREATING based control embedded within the application program 

EXECUTABLE CODE FOR OBJECT- code. An object-oriented messaging system, such as Object 

ORIENTED OBJECTS HAVING FINITE Management Group's Common Object Request Broker 

STATE MACHINE Architecture (CORBA) or Microsoft's Component Object 

FIELD OF THE INVENTION ^ Model (COM), provides management of distributed objects 

on heterogeneous client/server networks. Essentially, dis- 

This invention relates to methods and apparatus for ere- tributed objects are either on a client or a server's side of the 

ating executable code for objects and, more particularly, network. Application programmers build a main routine/ 

methods and apparatus for creating executable code for application program code for controlling execution flow and 

objects having user defined characteristics. for coding cUcnt distributed objects to request service from 

BACKGROUND OF THE INVENTION static server distributed objects. The messaging system 

An object, in the framework of object-oriented computer ^^'""^ ^^^'^l^' ^/ ^^^f «^ ^""^ P^^^ ^^T^^*^ ^° 

programming, is aa instance of a class that includes pieces ^ f ^^^^ 

of code called data and methods. Typically, the methods ^^'P^,^^ ^^^^"^ ^ ^ T .^^^^^^^^^^'^^y'. 

operate on private data, also caUed ^stance data, that the ^hent/server approach described above faik to give objects 

f . , ^ r^u• . J • J- r any abstract notion of behavior or control, forcme the 

object owns. Objects provide a programmine paradiem for ^ j . n [ , 

J • . n- * *u * • u • 1 Tl- programmer to develop the complex finite state-based con- 
creating intelhgent software that mirrors physical thmes. f . j - j . r i • 
Objects exhibit three properties that make them incredibly f ' code reqtiired o manage the use of any object used m 
•^r. 1 1 • u J 1 the client/server network. For example, there IS currently no 
useful: encapsulation, inheritance, and polymorphism. . j i ^ . • . . . r. t . i « 

w *u u- • 1 * 4 ■ u jj 20 way a standard C++ object can be defined to launch a remote 

Encapsulation means the object s implementaUon IS hidden .i. ji i_ j . i . 

P „^ . T u •/ ■ 1 event handler routine whenits data elements match a certain 

from pubhc view. Inheritance is the passing of class .. ...... , i- • . 

, , c * t J * • state without the programmer expucitly coding in the state 

resources or attnbutes from a parent class downstream ma . , , / ^ j-,- ... ^ • i- 

1 u-ui ni u- J and transition data conditions m the mam application pro- 
class hierarchy to a child class. Polymorphism means iden- , „ . . ^ ■ , ^ r . 
tical methods located in different objects can act differently. e""J for monitormg the object s data for a match 
. , , ^ n ■ ^ ... ,25 condition. In other words, manipulation of finite state-based 

1 '"i ^ . ^^'"f T i° ^ ' control is hidden from a creator of personalized objects 

classes 100 include data and methods. However control u„iess the creator is gifted with the programming knowledge 

mformation 102, whtch .s part of the code embodied m a j„ ^.^nip^ate state-based control in the application program 

computer program app ication is not directly associated Creation of distributed objects and related control is 

With the class, as illustrated bv the control mfornation s t-n n ^ - ^ a 

disassociation from the class lOO ^ essentially a programmer's job. A non-programmmg 

„^ , .„ , ■ type client/server manager must understand programming 

.J},^ J tUiistrates one form of control informaUon 102 go^e in order to change the finite state-based control behav- 

(FIG. 1). The three ovals 110 represent the different data ^n object. A simple to use interface for personalizing 

states an object of a particular class experiences during changing objects with object specific finite state-based 

execution of application program code. "State" is the cumu- 35 ^^^ij^i behavior does not exist, 

lative results of the behavior of an object, wherein at any . . ... 

given point in lime, the state of an object encompasses all of , ^he present invention is directed to overcoming the 

the (usuaUy staUc) properties of the object plus the cunent .""^^^ disadvantages. More speciflcally. the 

r u J • \ I u f *u A present invention is directed to providing a method and 

(usually dynamic) values of each of these properties. A ^ ^ 

f J. • - J -t-- * 1 apparatus for easily generating executable code for obiects 

minimum of one data state is required for descnbing control >in i • . . i t . , . 

• f ^ i- Tn, ji- tt-t *• «u J ^ * * With finite state -based control behaviors, 
mformation. The arrowed lines 112 connecting the data state 

ovals 110 indicate state transitions which include a transition 
method(s) executed when a specified data condition(s) is 
met. A state may have a single state transition or multiple In accordance with this invention, a method and apparatus 
unique transitions to other states. Essentially, the state 45 for automatically generating application program shell code 
diagram, FIG. 3, is an abstract representation of object for a predefined object-oriented application that is execut- 
operatioQ as determined by the underlying application pro- able by an operating system is provided. A predefined 
gram code. application can be any one of a number of different software 
Despite object usefulness, in the past, abstract notions applications capable of being implemented by an object- 
such as state-based control have not been directly related to 50 oriented program. 

objects (FIG. 1). In the past, state-based control has been The apparatus is a machine which includes a processor 

created at the application program code level by a highly with an object-oriented operating system running thereon, at 

skilled programmer. least one user interface device, memory and a display 

Software is available for allowing a user to easily define device, 

data without requiring the user to know the particulars of the S5 The method is a specification process resulting in each 

programming code, such as C++, of the objects. The proper object having a unique set of data, methods and finite 

code is generated according to user entered object informa- state-based control. First, an object name that represents a 

tion. However, the objects created must still rely on the physical object or other type of object used in the predefined 

state-based control programmed in the application program application is assigned. Then, at least one data name and 

code. In the past, there existed no easy way to create new eo method names are assigned to the named object according to 

objects or edit old objects that execute state-based control predetermined requirements. The assigned data and method 

different than that programmed in the application program names represent data and methods associated with the object 

code. Therefore,, in order to change or create state-based represented by the object name. Next, control information is 

control, reprogramming, or adding to, the original appUca- assigned to the named object. The control information is 

don program code was required. 55 assigned according to the control functionality associated 

Likewise, distributed objects, e.g., objects defined by data with the object in the predefined application represented by 

and methods used in client/server environments, have state- the assigned object name. Finally, application shell code 
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executable by an operating system is generated for the FIGS. 6-8 are flow diagrams of a method of automatically 
named object based on the assigned data and method names generating shell code according to the present invention; 
and the control information. piGS, 9-13 are display screen shots of a graphical inter- 
In accordance with other aspects of this invention, the f^ce tool for inputting data suitable for use in automatically 
assigned control information is further defined by assigning 5 generating shell code according to the present invention; 
at least one state name and assigning an object state ^. . . . ^. 

transition, if more than one sute is assigned. The object state ^ ^ schematic diagram illustrating a system 

transition is assigned at least one data condition and action. controUed by code constructs created by the present inven- 
Assignment of an action includes assigning a transition 

method name with at least one of a call function, or spawn FIG. 15 is a block diagram illustrating the class relation- 
function to the assigned transition method name, or assign- ship between the objects associated with the system depicted 
ing a nullification function according to the predefined in FIG. 14; 

application. Each assigned slate name represents a distinct fjgS. 16-26 are display screen shots iliustrating the 

state of the object in the predefined application. The object ^ ^^^^^ ^^^^ ^j^^ ^ ^^^^ ^ 
in the predefined apphcation is represented by the assigned t-t^ 1 • li 1 j- 

object name and each assigned condition of the data and ^ ^ ^^^^^ diagram illustratmg the effect objects 

transition method name. The data and transition method ^^^^ "^^^^^ "^^^^^^ system shown in FIG. 14; 

name represents a transition of the object, represented by the 

object name, between states as defined by the predefined FIGS. 28-34 are state flow diagrams for inputted data 

application. shown in FIGS. 16-26. 

In accordance with further aspects of this invention, the nnTAir nccr-DTrrrrnvr nc tuc 

generated application shell code is compatible with other p^p^pdp^ 
objects that communicate via an object-oriented messaging PREFERRED EMBODIMENT 

network. As will be better understood from the following 

In accordance with yet other aspects of this invention, a ^ description, the present invention provides a graphical inter- 
predefined application is mapped to a network of machines. face tool that allows a user to extend the definition of a 
Each machine is assigned a machine name. A server name is standard object of the type used in a typical object oriented 
then assigned to the assigned machine name, which repre- program to include expHcit finite state machine behavior, 
sents a server that is to be associated with the assigned See FIG. 2. Including a finite state behavior with object 
machine. Object names in the predefined application are definition allows a user to easily designate the specific 
then assigned to the server name. The automatically gener- information of an application program that operates upon 
ated apphcation shell code is then associated with the object object(s) defined by the user. The graphical interface tool, 
assigned to the server and server assigned to the machine. which is user friendly, allows a user to enter objects with 

As can be readily appreciated from the foregoing state information and, 'based on the entered information, 
summary, the invention provides a graphical control system 35 generates application shell code. While the example shown 

for automatically generating apphcation program shell code in FIGS. 14-33 and described below explains the invention 

for an object-oriented system according to a predefined in connection with creating objects and object control for a 

application. The graphical control system allows object drill system, it is to be understood that the invention can be 

information and associated control information to be easily used to describe objects in various other environments, 
entered via a single graphical user interface. Upon comple- ^ As shown in FIG. 4, the invention employs at the very 

tion of object-oriented information entry, the system gener- least a personal computer 130 including a display 132; a 

ates application shell code according to the operating system central processing unit (CPU) 134 that includes a processor, 

environment in which the system is running and the entered memory (RAM, ROM, hard drive etc.), interfaces, etc.; and 

object and object control information. The invention elimi- at least one user mput device (e.g., keyboard 136, mouse 

nates the need to program m or edit control application code 138, etc.). It will be apparent to those of ordinary skill in the 

by hand for each object defined in an apphcation. art that personal computer 130 may include many more 

Also, the control code for each object is directly associ- components, than those shown in FIG. 4. Such other com- 

ated with the object during construction and therefore is ponents are not described because they are conventional, and 

created in the same desired location as the object data. an understanding of them is not necessary to an understand- 
BRIEF DESCRIPTION OF THE DRAWINGS 50 ing of the present invention. 

r , A J. J addition to being operable on a single personal com- 

-Die foregoing aspects and many of the attendant advan- (^g. 4), the invention is also operable in a 

tages of this invention will become more readily appreciated ^^^^^^^ environment. An example of a suitable network is 

as the same becomes better understood by reference to the ^^^^^ 5 ^^.^^ ^ - j^^^ workstation 

followmg detailed description, when taken in conjunction ^^^^ j^^^ host server 142 to a 

Wiethe accompanying drawings wherem: chent/server-type network 144. The client/server network 

FIG. 1 ^ a block diagram of the associated object com- 144 includes an object-oriented messaging system, such as 

ponents of the prior known art; object Management GK)up's Common Object Request Bro- 

FIG. 2 IS a block diagram of the associated object com- ker (CORBA) or Microsoft's Component Object Model 

ponents according to the present invention; (COM), for controlhng distributed object communication 

FIG. 3 is an example state diagram further illustrating the between clients and servers. While the current embodiment 

control component of FIGS. 1 and 2; supports a standard ethemet bus, other types of networks, 

FIG. 4 is a schematic diagram illustrating a computer including non-wired networks, can be employed in actual 

system suitable for implementing the present invention; embodiments of the invention, 

FIG. 5 is a schematic diagram illustrating a computer 65 In order to better understand the preferred embodiment of 

network suitable for connecting together computer systems the invention described below, certain aspects of object- 

of the type illustrated in FIG. 4; oriented programmmg relevant to the following discussion 
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are first discussed. The fundamental aspects of object- The user is now ready to create a class. At block 154, the 
oriented programming is that objects can be organized into user creates a class simply by designating a name for the 
classes in a hierarchical fashion and that objects are inter- class. Also at block 154 the user defines data, methods (user 
pre table. Classes are abstract generic descriptions of objects methods) and states. The states include state names and 
and their behaviors. A class defines a certain category or 5 transitions between slates. The transitions include data con- 
grouping of methods and data within an object. Methods ditions and transition methods or actions. The actions that 
comprise procedures or code that operate upon data. Refine- occur at block 154 are illustrated in more deUil in FIG. 7 and 
ment of the methods of a class is achieved by the creation of described below. At block 157, the user stores the entered 
"sub-classes." A class can be thought of as a genus, and its information for later retrieval and editing, described below 
subclass as the species. Subclasses allow the introduction of with respect to FIG. 8. At block 158, the user prompts the 
a new class into the class hierarchy, subclasses inherit the system to generate application source code for: all of the 
behaviors of the higher class, from which they depend, plus defined classes; all of the assigned servers and machines; all 
new behaviors original with the subclass. of the data associated with the created classes; and any 

An instance of a class is a specified individual entity, operating system or network interfaces and to generate 
some thing concrete having observable behavior. An instance 15 MakeFile(s) for all assigned machines. Code generation is 
is a specific object with the behaviors defined by its class. automatically performed by a predefined algorithm that 
Instances are created and deleted dynamically. The class, retrieves the assigned and defined information and translates 
however, is the broad, yet abstract, concept under which the the retrieved information into the required code and inter- 
instance belongs. The instance inherits all the methods of its faces. The algorithm is essentially a compiler technique that 
class, but has particular individual values associated with it 20 parses the information entered into the graphical interface 
that are unique. There is only one location in memory of a tool and translates the parsed items into application shell 
computer for the class. There may, however, be numerous code. Preferably, the recursive descent compiler technique is 
instances of the class, each of which has different values and used. In order for successful algorithm operation, a grammar 
different physical locations in memory. The terms class and or a set of rules is created by the compiler writer for 
object are used interchangeably throughout this description. 25 describing the information entered into the graphical inter- 

The invention allows an application programmer to face tool prior to parsing. The compiler writer also creates a 

declare class definitions and state -based control for the translation scheme for translating the parsed items into 

declared class. Class definitions include data and methods application shell code. The generation step may be initiated 

accessible from outside a class. The state -based control after the user has completed information entry for a single 

includes user defined class states and data conditions with 30 class or multiple classes. The generated code includes 

transition methods. The transition methods are inaccessible method shell code files in which the user must enter a code 

from outside the class, because transition methods are pri- that defines user or transition methods in order for the 

vate methods unlike user methods which are public meth- application program code to be complete, see block 159. 

ods. Transition methods are associated with the functioning Compiling and linking the application source code is per- 

of the underlying application control. In other words, tran- 35 formed by running the autogenerated MakeFile(s) as shown 

sition method execution of a class directly relates to the in block 160. The step of running the MakeFile(s) is 

environment or application program that the user defined preferably performed after exiting the user interface tool, 

class is functioning in. An example of an environment or As shown in FIG. 7, class name is assigned, shown in 

application is a drilling cell of a computer networked block 165. Included with assigned class name are a selection 

controlled assembly line, which is illustrated in FIG. 9 and 40 of inherited base class(es), server name and autostart of class 

described below. option. Next is the assignment of publicly available data at 

FIGS. 6 and 7 illustrate the method of creating objects block 166 which includes basic data type or class aggregate 

with state-based control according to this invention. First, at for the assigned class. Methods for the assigned class are 

block 150, the user assigns the machines which will run the then assigned at block 168. At block 170, state names for the 

application. In the assign machine step the user enters the 45 assigned class are entered and at block 172 data conditions 

network node name of a machine and the IP address of the and related transition methods that define transitions 

user's machine. In one embodiment of the present invention, between the entered state names are entered, 

machines employ an operating system, such as UNIX or FIG. 8 illustrates the method steps for editing class 

Solaris. IP addresses identify the machine's location within information of previously created and stored classes. At 

the operating system and network. A more detailed, 50 block 174, the user retrieves the saved information of a class 

exemplary, illustration of machine assignment is shown in the user wishes to edit. The saved information includes 

FIG. 12 and described below. Next, at block 152, the user assigned machine name, server name, data name(s), user 

assigns one or more servers to a machine previously method name(s), and control information. At block 176, the 

assigned. The assigned server is a server designated to the user edits the retrieved information of the class. Using a 

assigned machine. The assigned server handles ss graphical interface tool of the type illustrated in FIGS. 9-13 

communication, object or application functions, with other and described below, the user edits any or all of the infor- 

servers on the same machine or servers associated with other mation previously assigned to a specific class. The user may 

machines connected together over a network. A server will reassign the class to another machine or redistribute server 

have one or more class objects assigned to it as described assignment. This software development tool is a simple and 

below. Multiple servers allow an application program to use 60 quick object creating tool that allows a user to adapt objects 

parallel processing. Asingle server can only process a single to physical components or application specific requirements 

application thread of an application program at a time. that change. The user then saves the edits at block 178. At 

However, rnultiple servers with objects spread throughout a decision block 180, the system determines if code was 

network allow parallel thread processing of an application previously generated for the retrieved class. If no previously 

program. The user can change the distributed topology of an 65 generated code exists, the system generates new code for the 

application by changing server assignment. See FIGS. 13 defined class, see block 184. However, if previously gener- 

and 14 and the related description set forth below. ated code exists, the system merges the previously generated 
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code for the retrieved class, see block 182, and proceeds to 
generate code for the newly edited class, see block 184. As 
will readily be appreciated by one of ordinary skill in the 
object-oriented programming art numerous types of code 
extraction and removal techniques can be appUed at the step 5 
depicted by block 182. 
Graphical Interface Tool 

FIGS. 9-13 illustrate a graphical interface tool according 
to one embodiment of this invention. The graphical interface 
tool easily enables a programmer or someone of lesser skill lO 
to enter the information required to describe classes and 
classes control. The graphical user interface tool allows a 
programmer or other user to perform the steps described in 
FIGS. 6-8. For case in understanding, the information 
entered into the graphical user interface tool described 15 
below defines a class. The class becomes an object when an 
running program calls the class thus instantiating it as an 
object. The graphical interface tool shown in FIGS. 9-13, 
allows a user to define a machine, a server for the machine 
or a server prestored within the machine from any worksta- 20 
tion or computer connected across a network. The display- 
able windows of the graphical interface tool include multiple 
interactive icons, buttons, field blocks and menus to enable 
ease in use. As will be appreciated by one of ordinary skill 
in the art similar but different interactive window displays 25 
may be tised to perform the tasks described below. Thus, the 
following description is to be taken as exemplary, not 
hmiting. The graphical user interface tool's main window 
258 is shown in FIG. 9 and described next. 

A user must first define the machine and server. Defining 30 
the machine and server designates the location a class and 
where associated control information is stored and per- 
formed. The activation of a define machines button 260, 
located in a button bar at the top of the graphical interface 
tool window 258, shown in FIG. 9 causes a machine 35 
definition window 290 (FIG. 10) to appear. The machine 
definition window allows a machine for storing and nmning 
objects later defined in the graphical interface tool to be 
defined. As shown in FIG. 10, the machine definition win- 
dow 290 includes a machine list section 292, a machine 40 
name block 291, an operation system (OS) block 293, 
library and Orbix path blocks 294 and 295 and compiler and 
Orbix option areas 296 and 297. The machine list section 
292 displays a list of machines attached to the network. After 
the user has selected the machine name from the machine list 45 
section 292, a machine name is displayed in the machine 
name block 291. In OS block 293, the user enters the OS of 
the designated machine by OS type. The OS type can be set 
to a default or selected by the user form a list of available OS 
types. Library path block 294 displays the location of library 50 
files important to the operation of the graphical interface tool 
and machine designation. The location of library files is only 
of importance to the user, if the user must place the library 
files in a location different from a default location. Orbix 
path block 295 displays the location of Orbix files. The user 55 
may relocate Orbix files, but these file generally are located 
at a known default. Orbix is a commercial object request 
broker (ORB) used by an embodiment of the present inven- 
tion to provide a transport -layer encapsulator that shields 
applications from the underlying transports of CORBA. In so 
this regard, as will be readily appreciated by those of 
ordinary skill in the object oriented programming art if one 
has to develop or use an object-oriented messaging system 
similar to CORBA with the present invention, an application 
for shielding applications from the underlying transports of 65 
the ORB is required. Other commercial ORBs operable with 
the present invention are International Business Machine 



Corporation's SOM, Digital Equipment Corporation's 
ObjectBroker, Sun Microsystem Corporation's DOE and 
Hewlett Packard Corporation's ORB Plus. 

In compiler options area 296, the user selects the option 
displayed if the included C++ compiler can support nested 
classes. Finally in Orbix options area 297, the user chooses 
the option displayed, if the Orbix or application used in 
place of Orbix can support multiple application threads. 

The user then designates a server for the designated 
machine or a server prestored within the designated machine 
by assigning a server name. To designate a server the user 
first activates a define servers button 262 located in a button 
bar at the top of the graphical interface tool window 258 
shown in FIG. 9. When this occurs, a server definition 
window 310 (FIG. 11) opens. The server definition window 

310 includes a server list section 311, a server name block 
312 and a machine name block 313. The server list section 

311 provides a list of servers on or available for use with the 
machine designated in machine definition windows 290 
(FIG. 10). The machine name assigned in machine definition 
window 290 is displayed in machine name block 313. Auser 
selected name from server list section 311 is displayed in 
server name block 312. 

Returning to FIG. 9, below the button bar section are 
displayed three other sections: an application name and 
objects section 263; an object interface section 268; and an 
object control section 278. The application name and options 
section 263 includes a current application pathname window 
264 and various on/off icons. The current application path- 
name window 264 displays the location name of a program 
that includes or will include the information entered into the 
graphical interface tool. The on/off icons include a debug 
console icon 265, an object display icon 266 and an excep- 
tion TRY blocks icon 267. Activation of these icons prior to 
code generation adds various debugging qualities to the 
generated code. The debug console icon 265, when activated 
to the on position by the user, inserts debugging code into 
generated code. The object display icon 266, when activated, 
adds code to the generated code for displaying class 
attributes to one viewing the generated code. The exception 
TRY blocks icon 267 also allows entry of extra code into 
generated code. The code entered by an activated exception 
TRY blocks icon 267 adds code that allows a programmer to 
easily identify a cause if an error is experienced. 

Object interface section 268 includes a define class button 
270, a define data button 272 and a define user method 
button 274. The areas below each button displays user 
selections. Selection of these buttons retrieve respective 
interactive windows. As shown in FIG. 12, a class definition 
window 316 opens upon activation of the defined class 
button 270. The class definition window 316 includes a class 
name block 317, a auto start selector 318, an include path 
block 319, a base class block 320, a server name block 322, 
a machine name block 323 and a headers and macros section 
324. In class name block 317, the user enters a class name 
that is associated with a property of the class that is being 
described. This entry will be better understood from the 
exemplary embodiment of the invention illustrated and 
described below. Enabling the auto start selector 318 causes 
the generated code of the class identified to instantiate an 
object of that class at start-up. The include path block 319 
displays the stored location of the class name specified in the 
class name block 317. In base class block 320, the user 
specifies any inheritance for the class identified in the class 
name block 317. The server selected in the server definition 
window 310 is displayed in server name block 322. The user 
has the option of changing the name of the server designated 
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to the defined class name by retrieving a server list from a 
pulldown menu. The machine name selected in machine 
definition window 290 is displayed in machine name block 
323 automatically after server selection. Finally, in the 
headers and macros section 324, the user enters comments, 5 
global class definitions or similar code for execution or 
display within the to-be-generated shell code. 

Activation of define data button 272 (FIG. 9) opens a data 
definition window 325, shown in FIG. 13. The data defini- 
tion window 325 includes a class name block 326, data lO 
member name block 327, a data parameter selection section 
328, a data type selection section 330 and an initial value 
definition section 331. The class name block 326 displays 
the class name assigned in class definition window 316. In 
data member name block 327, the user enters a name for one 15 
type of data the user wishes to assign to the class name 
displayed in class name block 326. In data parameter selec- 
tion section 328, the user determines the parameter type of 
data defined for the data member named in data member 
name block 327. The data parameter selection section 328 20 
options include a scalar parameter (a single value), an array 
parameter (multiple values in an array setting), or a sequence 
(a CORBA sequence unique to CORBA). In data type 
section 330, the user selects the data type for the data 
identified by the name entered in the data member name 25 
block 327. The user can define the data as one of the 
following: character; octet; Boolean; unsigned short; short; 
unsigned long; long; float; double; string; enumeration; any 
or Contained Class. All data types in section 330, except for 
'contained class/ are CORBA data types. When selected, 30 
contained class, section 332a, is an aggregate class data 
element. As will be appreciated by one of ordinary skill in 
this art, the underlying architecture determines the data types 
available for use. After the user has selected one of the data 
types from data type section 330, the user enters a value in 35 
the initial values section 331 of the selected data type. If the 
user selects the Contained Qass data type the user enters a 
predefined class name into the Contained Class data type 
initial value 332. The predetermined class name entered into 
the Contained Class data type initial value 332 is an aggre- 40 
gate of the class name displayed in class name block 326. 

Returning to FIG. 9, after selecting the define user method 
button 274, the user enters names of \iser methods, thus 
completing the basic definition of the class and its public 
interface. 45 

Also shown in FIG. 9, the object control section 278 
includes a define state section 280, a define transition section 
282, and a define transition methods section 284. Each 
section of object control section 278 includes a button for 
activating entry of information. In the define state section 50 
280, the user enters the names of the states that are experi- 
enced by the object class entered in define class section 270. 
Preferably, the user enters state names that uniquely describe 
states the defined class experiences. An example of this entry 
is shown in more detail in FIGS, 26-32 and described below. 55 
In the define transition section 282, the user enters any 
transitions between states identified by the entered state 
names. A transition includes a data condition and a corre- 
sponding action. Essentially, the user is defining the action 
performed on an object if a data condition is met when the 60 
object is in a specific state. The data condition can be a 
specific value of the data entered in the data definition 
window 325 or an open set of data representing any data 
condition. The designated Actions may be one or more of the 
following functions: a call or spawn of a transition method, 65 
or a null- A call calls an action that executes and returns. A 
spawn causes the cuaent apphcation thread to fork into a 



secondary thread with priority set by user, then performs an 
action and returns. Finally, a null action automatically 
unlocks the object's data and returns, essentially performing 
no action. Transition method names that are assigned to an 
action are entered by the user in the define transition 
methods section 284. 

After the user has completed entry of the information into 
object interface section 268 and object control section 278, 
the user can double -check the entered data specific to the 
object control by displaying the state diagram of the defined 
class. A display state diagram button 288 located in the 
button bar of graphical interface tool window 258, when 
activated, allows a user to view a state diagram for the class 
defined. The information entered into the windows associ- 
ated with the graphical interface tool window 258 is stored 
in a GUI model that includes structures, linked Ust, etc. A 
display generator retrieves the control information stored in 
the GUI model and displays it in a predefined location on the 
display for presenting a state diagram, i.e., state names are 
displayed in ovals representing object states. An example of 
such a display is illustrated in FIGS. 28-33 and described 
below. 

Once the \iser is fully satisfied with the information 
entered into graphical interface tool window 258, the user 
activates a generate code button 286 that causes application 
shell code based on the information entered to be automati- 
cally generated. The generated code is called application 
shell code because all code is generated except the specific 
code for any user method names entered in define user 
method section 274 and any transition method names 
entered in define transition method section 284. The specific 
code for these two types of methods must be entered into 
specific locations within the application shell code. The user 
may either enter user and transition method code in the 
graphical interface tool through an edit function or outside 
the graphical interface tool through a file editor that allows 
a programmer to edit and enter code. The user and transition 
method code entered in the graphical interface tool is 
automatically entered into the application shell code upon 
activation of the generate code button 286. 

EXAMPLE 

Embodiment 

FIG. 14 is a schematic illustration of an exemplary 
apphcation of the present invention. The illustration com- 
prises a production system 200 for drilling holes in parts. 
The production system 200 includes a transport 212 pow- 
ered by transport motor 214, The transport transports a 
palette 210 that supports part 208 to be drilled to a drill 
assembly 219. The transport 212 includes one or more 
sensors 216 for sensing when palette 210 is properly posi- 
tioned. The drill assembly 219 includes a vertical support 
221 for receiving a horizontally mounted elevator 222 that 
moves vertically on the vertical support 221. Attached to the 
outer end of the horizontally mounted elevator 222 is a drill 
motor 220 that extends over the transport 212, at a pre- 
defined position. The driU motor 210 rotates a vertically 
oriented drill 218. 

In operation, the transport motor 214 causes transport 212 
to move the palette 210 imtil the sensor(s) 216 senses that 
the palette 210 is in the appropriate position. When the 
palette 210 reaches the appropriate position, the transport 
motor 214 shuts off stopping operation of the transport 212 
and, thus, movement of the palette. It is assumed that the 
position of the part 208 on the palette 210 is precisely known 
and that each time a part is placed on the palette the part is 
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placed in precisely the same position. Therefore stopping of includes the PalettePositioned and DrillEnabled data and no 

the palette 210 at a precise location places the part 208 at a user methods. DrillWorkCell has five possible states defined 

precise location relative to the drill assembly 219. In this by state names entered in the define state section 280fl. The 

example, the transport motor 214 is a single speed motor, states are: Off; WaitingForPalette; WaitingForDrillEnable; 

i.e., the transport motor is either on or oflf, and the drill motor 5 Drilling; and WaitingForPalette Clear. DrillWorkCell 

220 IS a variable speed motor. After the palette 210 is i^^i^des six transitions between the states and four named 

positioried the part 208 is ready to be dnUed by the drill transition methods shown in sections 282^ and 284^, respec- 

assembly 219. First the speed of the d^^^^ ^hese transitions and transition methods are 

the proper dnlhng speed for the drill 218. Then the hon- a^^J^u^a ;„ ™™ i.„i„„, • * * j- u 

, ,1 * J 1 . -1 J A 1 . described in more detail below in a state diagram shown m 

zontally mounted elevator 222 is lowered. As the elevator 28 ^ xu 

222 is lowered, the driH 218 drills a hole in the part 208. ^ . 

After drilling is complete, the horizontally mounted elevator , /J^^^* ^'^7^ interactive windows similar to FIGS. 

222 raises the drill 218 above that the part 208 and the drill ^^^^ containmg user entered and default information asso- 

motor 220 is turned off. Next, the transport motor 214 is ""^^^^^ DnllWorkCell class. The machine definition 

energized, causing the transport 212 to move the palette 210 , wmdow 290a shown in FIG. 17, opened when the define 

away from the drill assembly 219. After the palette is ^achme button 260a (FIG. 16) is activated shows that the 

removed, system 200 waits for another palette to be placed selected the machine named System ControLer from 

on the transport machine list section 292a. The machine list section 292fl 

Also shown in FIG. 14 are computer work stations that T^^t^'^'^''^^^^ A^l m tl '1!°'^" ^ ^c^'/^ 

interact with various components of the production system ^^^^"^ ^^^J"' ^^'^^^^ ^c?.*^ 

200 for controUing the operation described above. A trans- '° "^^^^^^^^f !f Tifn?".^^?"^ ^.'1^ "''^ 

port controller 204 is connected to the sensor(s) 216 and to Orbix path block 295a display default address 

the transport motor 214. A drill controller 206 is connected ^""""^''f^ respective associated components. The 

to the horizontally mounted elevator 222 and to the drill . "^"'P,^'' ^r^^ 296a and the Orbix options area 297a 

motor 220. A system controUer 202 is connected to the drill ^ "'^^^^ ^ ^^^^^"^ miplementation. 

controller 206 and transport controller 204. The system The server definition wmdow 310fl shown in FIG. 18 that 

controUer provides overall production system control. Sys- opened when the define server button 262a (FIG. 16) is 

tem controller 202 is also connectable to a client/server activated shows klatul as the designated server, Klatul also 

network that may include other computer controllers that appears in the server list section 311a along with other 

control other operations (not shown) performed on part 208 3Q available servers. 

or other parts associated with a final assembly. The class definition window 316a shown in FIG. 19, 

It is well understood that an object-oriented program which opens when the class definition button 270a is acti- 

operating on the computers 202, 204, and 206 can effectively vated displays information related to DrillWorkCell. Auto 

control the physical components of the production system start selector 318a has been selected, therefore DrillWork- 

200. Once the programmer has determined the control 35 Cell will automatically be instantiated upon start-up of 

required for the appUcation described above, the program- production system 200. Include path block 319a is empty, 

mer creates classes that represent the physical components because DrillWorkCell class is defined in this application 

of the production system 200. Then, the programmer gen- ^ "ot retrieved from another application. Base class 

erates the code necessary to perform the application specific block 320a displays dome_DataClass. Dome_DataClass is 

operations on the created classes. 40 the base class for classes that do not have a formal parent 

FIG. 15 is a class hierarchy diagram for the production Similar to base classes in other object-oriented 

system depicted in FIG. 14 and implemented in the manner environments, Dome_DataClass contains the information 

shown in FIGS. 16-26 and described below. The highest required for this embodiment of the present invention to be 

class is denoted DrillWorkCell 400. Two classes denoted operable. Server name block 312a and machine name block 

Drill 402 and Transport 404 are aggregates of the Drill- 45 ^^^^ and SystemControUer, respectively. No 

WorkCell class 400. Two classes denoted Elevator 406 and information has been entered into headers and macros 

Variable Speed Drill Motor 408 are aggregates of Drill class section 324a. 

402 and two classes denoted Transport Motor 410 and The data definition window 325fl, shown in FIG. 20, 

Sensor(s) 412 are aggregates of Transport class 404. Aggre- which opens when the define data button 272a (FIG, 16) is 

gate assignments are defined in the classes data definifion 50 activated, shows Cell Transport data 327a has been entered 

window(s) 325 (FIG. 13). Dashed line 416 illustrates the fact and the array parameter 328fl selected. In data type selection 

that the Variable Speed Drill Motor class 408 has assigned section 330a the data PalletPositioned has been designated 

inheritance from the Transport Motor class 410. The graphi- as Transport in the type contained class. Therefore, instan- 

cal interface tool depicted in FIGS, 16-26 and described tiation of Cell Transport data will instantiate Transport class, 

below can be run on any of the controllers shown in FIG. 14, 55 because of the aggregate relationship assigned in the data 

namely the transport controller 204, the drill controller 206, type selection section 330a. 

the system controller 202, or any compatible computer FIGS. 21-26 illustrate the information entered into 

system connected via the network to the system controller graphical interface tool window 258 for all the other defined 

2^2. classes for production system 200. For ease of illustration 

FTGS. 16-20 show the entered object interface informa- 60 and in order to avoid unnecessary repetition, the individual 

tion and object control information for class DrillWorkCell windows that are opened when the above described buttons 

400. For ease of understanding the reference numbers used are activated are not illustrated. FIG. 21 illustrates Drill class 

with the objects displayed in FIGS. 16-26 are the same as 403, which represents the drill 218. FIG. 22 illustrates the 

those used in FIGS. 9-13 with the addition of an "a" to Transport class 404, which represents the transport 212. 

distinguish between the FIGURES. As shown in FIG. 15 and 65 FIG. 23 illustrates the Elevator class 406, which represents 

described above, DrillWorkCell is the class that represents the elevator 222. FIG. 24 illustrates the Sensor class 412, 

producrion system 200 (HG. 14). Class DrillWorkCell which represents the sensor(s) 216. FIG. 25 illustrates the 
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Transport Motor class 410, which represents transport motor BcamClear. One state transition is listed in the define 

214. FIG. 26 illustrates the Variable Speed Drill Motor class transition section 282^, which is defined in the define 

408, which represents the multispeed motor, drill motor 220. transition method section 284^ as Sample Motor Speed. 

The Drill class definition window 258b shown in FIG. 21 illustrated in the Variable Speed Drill Motor 
displays user inputted information for the Drill class. As 5 ^^"^^^ ^'^^'^"^ described below, 
shown in the defined data section 2726, Drill class includes . Before describing the individual state diagrams, it is 
the DrillEnabled, MotorSpeed and PaUetPosition data. As important to get a better understanding of the interrelation- 
shown in the defined state section 2806, the Drill class "^A • W v^^^^ n n'',?'^^'^^^^^^^ 
exhibits five states defined by the state names: Off, Wait- f^^l^t^.T^S^ 

* 1? * e J 117 1-1-1 .1 T- T>. in IS Transport S 426 is Sensor; E 428 is Elevator; TM 430 IS 

mgForMotorSpeed; WaitingForEW^^^ 10 TransportMotor; V 432 is VariableSpeedDriUMotor. As 

cen^ WaitingForElevatorZ; and WaitingForAscent The .^own in FIG. 27, the objects are represented in the same 

Drill class also mcludes transitions between states listed m hierarchical manner as FIG. 15. Also included are arrows 

the defined transition section 2826. Five transition methods t^at show any affects one object has upon other objects. The 

and a nuU are fisted in the defined transition section. Tlie ^^^^^ ^nd attached titles represent the execution of an 

defined transition method section 2846 defines the 15 action which corresponds to a specific transition method(s). 

transitions, which are also shown m parenthesis in the define p^^ example, two arrows begin at DWC 420. A first arrow 

transition section 282fl. T^ese transitions are belter shown in extends to D 422. TTie first arrow includes the actions Enable 

a Drill state diagram (FIG. 29) and described below. d^ii and Report which indicates the DrillWorkCell object 

The Transport class definition window 258c is shown in determines when the drill starts operations and requests Drill 
FIG. 22. The defined class 270c of this window notes that status. The actions Enable Drill and Report correspond to the 
the class in Transport. The define data section 272c includes transition methods CommandDrillSequence and 
TransportEnabled and BeamBlocked data. The define state ReportCompletion, respectfully. A second arrow extends to 
section 280c notes that the Transport class includes the Idle, T 424. The second arrow includes the action Enable Trans- 
Receiving and Sending states. The defined transition section port which indicates the DrillWorkCell object determines 
282c of the Transport class lists two transitions and a null. ^ when the transport can begin operation. The action Enable 
The defined transition method section 284c identifies the Transport corresponds to the transition method Receive - 
two transition methods. The states and transitions arc better FirstPallet created for the DrillWorkCell object, 
illustrated in a Transport class state diagram shown in FIG. p 422 has three arrows extending from it. A first arrow 
30 and described below. ^[xh the action Determine Drill Status corresponds to the 

As shown in FIG. 23, the defined data section 272i/ of the ReportCompletion transition method. The first arrow 

Elevator defined class 270^^ includes the TargetPodDepth extends to DWC 420, thereby reporting drill status to the 

and CunentPodDepth data. Pod corresponds to elevator. The Drill Work Cell. A second arrow with actions Set Target 

defined state section 280rf of the Elevator class includes four Elevator Position and Enable Elevator Motion extends to E 

states: Off; PodStationary; PodDescending; and PodAscend- 428. According to the second arrow actions, D 422 sets the 

ing. The defined transition section 2S2d of the Elevator class target elevator position and enables elevator motion, respec- 

hsts user defined transitions between the Elevator class lively. The Set Target Elevator Position action conesponds 

states. Four transitions, which are defined in the transition to the CommandDescent transition method and the Enable 

method section 284d are fisted. They are: SamplePodDepth; Elevator Motion action corresponds to the CommandAscent 

LowerPod; RaisePod; and HaltPod, These states and tran- ^ transition method. The final arrow extending from D 422 

sitions are better illustrated the Elevator state diagram extends to TM 430. As per the third arrow*s action, Com- 

shown in FIG, 31 and described below. mand TM (transport motor) to Start or Stop, D 422 com- 

As shown in FIG. 24, the define data section 272e of the mands the transport motor to begin or stop operation. The 

Sensor defined class 270e includes BeamBlocked data. As commands indicated by the third arrow correspond to the 

shown in the define state section 280e, the Sensor class 45 ComrhandMotorOn and CommandMotorOff transition 

includes three states: Off; BeamClear; and BeamBlocked. methods of the Drill object. 

The Sensor class includes one transition method and two T 424 also has three arrows extending from it. A first and 

nulls shown in the define transition section 282e listed in the second arrow includes the action Move Pallet. The first 

define transition method section 284e. The states and tran- arrow extends to DWC 420 and the second to D 422. The 

sitions of the Sensor class are better iUustrated in the Sensor Move Pallet action corresponds to the StartBelt and StopBelt 

state diagram shown in FIG. 32 and described below, transition methods. Essentially, the Transport reports to the 

As shown in FIG. 25, the define class section 270/ of the Drill and Drill Work Cell that the pallet is in motion. The 

Transport Motor class window displays Transport Motor to third arrow extends to TM 430 with the action Command 

identify Motor class. The define data section 272/ fists Motor TM to Start or Stop. These actions also correspond to the 

Enabled data. The Motor class includes two defined states, 55 StartBelt and StopBelt transition methods. 

Off and On, shown in the define state section 280/ Two S 426 has one arrow extending to T 424, The arrow 

transition nulls are listed in the define transition section 282/ includes the action Determine Pallet Position which corre- 

No transition methods are required for Motor class, as sponds to the Sense transition method. The Sensor is tefiing 

shown in the define transition method section 284/ These the Transport where the pallets are presently located, 

are better illustrated in the Transport Motor state diagram eo E 428 also has one arrow extending from it. This arrow 

shown in FIG. 33 and described below. only affects E 428 as indicated by the arrow pointing back 

As shown in FIG. 26, the define class section 270g of the at E 428. The actions performed are determining current 

Variable Speed Drill Motor class window 258g displays the elevator depth and lowering, raising and halting the elevator, 

variable speed Drill Motor class. As shown in the define data The corresponding transition methods are SamplePodDepth, 

section 272g^, the Variable Speed Drill Motor class includes 65 LowerPod, RaisePod and HaltPod, respectively. 

MotorSpeed data. The define state section 280g of the TM 430 also has a recursive arrow. The action associated 

Variable Speed Drill Motor class includes two states: Off and with the arrow indicates when to turn the motor on or off. 
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This actioQ corresponds to the TurniMotorOn and TumMo- 
torOff transition methods. 

V 432 has one arrow extending to D 422. The arrow 
action performed is a determination of the motor speed. This 
action corresponds to the SampleMotorSpeed transition 
method. 

As noted above, state diagrams for the various classes are 
illustrated in FIGS. 28-34, Each of the states of the related 
class is displayed as an oval. The lines with arrows that 
interconnect the oval states indicate transitions from one 
state to the other in the direction of the arrows. The data 
condition and action defined in the define transition section 
of the related class interface (FIGS. 15 and 16-26) is 
displayed at the midpoint of each transition line. For 
example, as shown in FIG. 28, the transition line 340 
between the Off state 342 and the WaitingForPalette state 
344 of the DrQl Work Cell class corresponds to the data 
condition and corresponding action entered in define tran- 
sition section 282 for the first defined transition from the OS 
state 342. Transition line 340 illustrates a transition from the 
DrillWorkCell object Off state 342 to the WaitingForPalette 
state 344. This transition occurs if the PalettePositioned data 
is false, i.e., Palette Positioned data indicates that the palette 
is not in position for drilling when the DriUWorkCell object 
is first turned on. The action performed in this first transition 
is a spawn of transition method ReceiveFirstPalette at pri- 
ority 4, indicated by the words spawn.P4 in the define 
transition section 282a of the Drill Work Cell class window 
(FIG. 15). In this regard, any number of priority levels may 
be made available — ten, for example. Preferably, level 1 is 
the highest priority level available. Setting a priority level 
for an action determines the actions relative importance to 
other actions being performed concurrently. For ease of 
description and in order to avoid undue complexity, all 
priority levels of the example of the application - of the 
invention being described are set at four, meaning that no 
action is more important than another. 

l\iming now to a more detailed description of the Drill 
Work Cell state diagram shown in FIG. 28, when production 
system 200 is started, the DrillWorkCell class is instantiated 
by a user input thus becoming DrillWorkCell object. The 
DrillWorkCell object first enters the Off state 342. As soon 
as a Palette Positioned data value is determined, the Drill- 
WorkCell object's state immediately transitions. If the Pal- 
ettePositioned (PP) data value is false, the DrillWorkCell 
object transitions to the WaitingForPalette state 344. This 
transition spawns a transition method denoted ReceiveFirst- 
Palette. Conversely, if the PalettePositioned data value is 
true, the DrillWorkCell object transitions to the WaitingFor- 
DriUEnable state 346. This transition spawns a transition 
method denoted CommandDrillSequence (CDS). If the 
DrillWorkCell object transitions to the WaitingForPalette 
state 344, the DrillWorkCell object remains in this state until 
the PalettePositioned data value becomes true. When this 
occurs, the DrillWorkCell object transitions to the Waiting- 
ForDrillEnable state 346. When this transition occurs, the 
CommandDrillSequence transition method is spawned. 

The DrillWorkCell object remains in the WaitingForDril- 
lEnable state 346, until a transition to Drilling state 348 
occurs. A transition to Drilling state 348 occurs when the 
DrillEnable data value becomes true. No action transition 
method is spawned when the transition from the Waiting- 
ForDrillEnable state 346 to the Drilling state 348 occurs 
from the Drilling state 348, as indicated by the null notation. 

The DrillWorkCell object transitions, to the WaitingFor- 
PaletteClear state 350, when the DrillEnable data value 
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becomes false. This occurs when the drilling process is 
complete. When the transition from Drilling to WaitingFor- 
Palette Clear occurs, a RcportCompletion transition method 
is spawned. The DrillWorkCell object transitions from the 
WaitingForPaletteClear slate 350 to the WaitingForPalette 
state 344, when PalettePositioned data value is false. When 
this transition occurs, nothing occurs as signified by the 
Null. The DrillWorkCell object state information is used to 
control the generation of the code needed to control the 
overall functionality of the production system 200. 
Essentially, the system, as it relates to the DrillWorkCell 
object, waits for a palette to be positioned. After the palette 
is positioned, the DrillWorkCell object waits for completion 
of the drilling process. Next, the DrillWorkCell object waits 
for the palette to be removed; and, then, waits for the next 
palette. 

A user is able to display the state diagram shown in FIG. 
28 by activating the display state diagram button 288 in the 
button bar of the DrillWorkCell class window 258^ (FIG. 
16) prior to actuating the generate code button 286a. After 
the user has reviewed the state diagram and all other 
information entered into the window, the user is ready to 
cause the code for the DrillWorkCell class to be generated. 
To generate the code, the user simply activates the generate 
code button 286fl located in the button bar of the graphical 
interface tool window 258c. In the DrillWorkCell example 
of FIG. 16, the class library for DrillWorkCell with the 
included PalettePositioned and DrillEnabled data is gener- 
ated. DrillWorkCell code is generated according to the 
information entered in the object control section of 278. An 
empty shell coat is created for inputting the specific code for 
the transition method names assigned to the DrillWorkCell 
class. No shell coat is created for user methods because no 
user method names were entered into the define user method 
section 274a of the DrillWorkCell class window. 

Preferably, the drilling system of FIG. 14 is connected via 
the system controller 202 to an object oriented messaging 
system common object request broker architecture 
(CORBA). In order for the drilling system of FIG. 14 to take 
advantage of fully distributed object-oriented architecture, 
in such a system, the code generated by the invention must 
include interface code that allows the invention to commu- 
nicate in a CORBA environment. More specifically, the 
generated interface code must include a remote procedure 
called (RPC) interface file, an interface definition language 
(IDL) interface file, an RPC server code file, a CORBA 
server code file, Ada bindings for RPC files and a make file. 
Further, the RPC interface file must be precompiled by an 
RPC precompiler to generate a set of RPC files and the IDL 
interface file must be precompiled by an IDL precompiler to 
produce a set of CORBAfiles. RPC, CORBA, IDLand make 
files and Ada bindings are commonly known files for 
executing client/server distributive object communication in 
a CORBA or RPC environment. The final files created are 
application program interface (API) code files. The API code 
files provide a level of abstraction between the generated 
files (CORBA or RPC) and the created class information 
with any associated class control. The API code files allow 
state -based control to be directly associated with the an 
object. 

As shown in FIG, 29, the Drill class state diagram 
includes all the information entered in the object control 
section 278b of the Drill class window (FIG. 21). As shown 
in FIG. 29, when the Drill class is instantiated the Drill 
object immediately enters an Off state 352. The Drill object 
remains in the off state until DrillEnabled data value is true. 
When this occurs, the DriU transitions from the Off state to 
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a WaitingForMotorSpeed state 354. When this occurs, a method is spawned. If the CurrentPodDepth data value is 

CommandMotorOn transition method is spawned. When the less than the TargetPodDepth data value, the Elevator object 

MotorSpeed data indicates that the speed of the drill motor transitions from the PodStationary state 372 to a PodDe- 

is equal to or is greater than some predefined value, such as scending state 374. When this transition occurs, a LowerPod 

300 RPM, the Drill object transitions from the WaitingFor- 5 transition method is spawned. If however the CunentPod- 

MotorSpeed state 354 to a WaitingForElevatorl state 356. Depth data value is greater than or equal to the Targe tPod- 

CommandDescent transition method is spawned. When the Depth data value, the Elevator object transitions from the 

PalcttePositioned data value becomes true, the Drill object PodStationary state 372 to a PodAscending state 378. When 

transitions from the WaitingForElevatorl state 356 to a this transition occurs, a RaiscPod transition method is 

WaitingForDescent stale 358. spawned. 

When the PalcttePositioned data value becomes false, the When the Elevator object is in the PodDescending state 

Drill object transitions the WaitingForDescent state 358 to a 374 and the CurrentPodDepth data value becomes greater 

WaitingForElevator2 state 360. When this transition occurs, ^^^^ ^^^^ ^0 ^® TargetPodDepth data, the Elevator object 

a CommandAssent transition method is spawned. When the transitions to the PodStationary state 372. When this tran- 

PalettcPositioned data value shifts back to true, the DriU sition occurs, a HaltPod transition method is spawned. When 

object transitions from the WaitingForElcvator2 state 360 to 1*?^ Elevator object is in the PodAscending state 378 and the 

a WaitingForAscent state 362. When this transition occurs, CurrentPodDepth data becomes less than the TargetPod- 

a CommandMotorOff transition method is spawned. Since P^P^^ ^^'f^l''^''' ^^^^^^ trausitions to the PodSta- 

the PaletteP.^^^^^^^^ true, immediat^^^^^^^^^^ ^^Z^/;^^ 

f ri/^?".K''^!'v T^^^^ ? . Elevator state diagram (FIG. 31) depicts the operation of the 

state 362 to the WaitingForMotorSpeed state 354. When this ^j.^^j^^ 222 (FIG. 14). The present elevation of the elevator 

transition occurs, a ReportCompletion transition method is 222 is determined. If the position is higher than the target 

spawned. Essentially, the process illustrated m the Dnll state position of the elevator, the elevator 222 is lowered. If the 

diagram shown in FIG. 28 describes the performance of the present position is equal to the target position of the elevator, 

drill 218. The drill 218 begins with its motor in an off state. ^5 the elevator 222 is raised. The elevator becomes stationary 

The drill motor is turned on when commanded. Then the when the elevator height is lower than or equal to the target 

system waits for the speed of the motor to reach a predefined height. 

hmit. After the limit is reached and the palette is properly FIG. 32 is a state diagram for the Sensor class (FIG. 24). 

positioned, the drill descends with the elevator 222. Next, Upon instantiation of the Sensor class, the Sensor object 

the drill rises with the elevator 222, the drill motor is turned 33 enters an Off state 380. The Sensor object unmediately 

off, completion of the task is reported and the sequence of transitions from the Off state 380 to a BeamClear state 382. 

operations is repeated. When this transition occurs, a Sense transition method is 

FIG. 30 is a state diagram for the Transport object. When spawned. When the Sensor object is in the BeamClear state 

instantiated, the Transport object begins in an Idle state 364. 382 and the BeamBlocked data value becomes true, the 

If the TransportEnabled data value is true and the sensor 35 Sensor object transitions to a BeamBlocked state 384. No 

BeamBlocked data value is false, the Transport object tran- transition method is spawned when this transition occurs, as 

sitions from the Idle state to a Receiving state 366. When indicated by the null notation in FIG. 32. When the Beam- 

this transition occurs, a StartBelt transition method is Blocked data value becomes false, the Sensor object tran- 

spawned. If the TransportEnabled and SensorBeamBlockcd sitions from the BeamBlocked state 384 to the BeamClear 

data values are both true, the Transport object transitions 40 state 382. Again, no transition method is spawned when this 

from the Idle state to a Sending state 368. When this transition occurs, as indicated by the null notation, 

transition occurs, a StartBelt transition method is also Essentially, the sensor object (FIG. 14) determines if a 

spawned. palette is in the drilling position based on the BeamBlocked 

If the SensorBeamBlocked data value becomes true when ^^1^ value, 
the Transport object is in the Receiving state 366, the 45 FIG. 33 is a state diagram for the TransportMotor class 
Transport object transitions back to the Idle state 364. When (FIG. 25). The TransportMotor object has two states — an 
this transition occurs, a StopBeh transition method is Off state 386 and an On state 388. The TransportMotor 
spawned. If the Sensor's BeamBlocked data value becomes object transitions from the Off state 386 to the On state 388 
false when the Transport object is in the Sending state, the when the MotorEnabled data value is true. The Transport- 
Transport object transitions to the Receiving state 366. No 50 Motor object transitions from the On state 388 and the Off 
transition methods are spawned when this transition occurs, state 386, when the MotorEnabled data value is false, 
as denoted by the nuU indication. Essentially the following Neither transition spawns a transition method, as indicated 
occurs, when enabled, the transport object checks to see if by the null notation in FIG. 32. 

the sensor beam is or is not blocked. If the sensor beam is FIG. 34 is a state diagram for the VariableSpeedDrillMo- 
blocked, indicating that no palette is in position for drilling, 55 tor class (FIG. 26). The VariableSpeedDrillMotor object has 
the transport motor is started to move a palette into position. two states — an Off state 390 and a BeamClear state 392. 
The transport motor is stopped when a palette is in position Starting in the Off state, the VariableSpeedDrillMotor object 
for drilling. If the sensor beam is not blocked when the immediately transitions to the BeamClear state 392 when 
transport object is enabled, indicating that a palette is in instantiated. When this transition occurs, a SampleMo tor- 
position for drilling, the transport motor is started to move 60 Speed transition method is spawned, 
the palette away from the driUing position. The FIGS. 33 and 34 state diagrams depict the functioning 
FIG, 31 is a state diagram for the Elevator class (FIG. 23). of the transport motor 214 and the drill motor 220 (FIG. 14). 
When the Elevator class is instantiated the Elevator object is The transport motor 214 is either on or off depending upon 
placed in an Off state 370, the Elevator object immediately enablement. The VariableSpeedDrillMotor object provides 
transitions from the Off state 370 to a PodStationary state 65 continuous information regarding the speed of the drill 
372. When the transition from the Off state 370 to PodSta- motor as evidenced by the SampleMotorSpeed transition 
tionary state 372 occurs, a SamplePodDepth transition method. 
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While the presently preferred embodiment of the inven- 
tion has been illustrated and described, it is to be understood 
that various changes can be made therein without departing 
from the spirit and scope of the invention as defined by the 
appended claims. 

The embodiments of the invention in which an exclusive 
property or privilege is claimed are defined as follows: 

1. A method for automatically generating apphcation 
program shell code for a predefined application in an object- 
oriented system, said system comprising a processor with an 
operating system running thereon, at least one user interface 
device, memory and a display device, said method compris- 
ing: 

(a) assigning an object name, wherein the object name 
identifies an object operable in the predefined applica- 
tion; 

(b) assigning at least one data name to the assigned object 
name according to predetermined requirements for the 
object; 

(c) assigning a method name to the assigned object name 
according to predetermined requirements for the 
object; 

(d) assigning control information to said assigned object 
name according to said predefined application, wherein 
said assigning control information includes: 

(i) assigning at least one state name, wherein each state 
name identifies a distinct state of the object; and 

(ii) assigning an object state transition, if more than one 
state is assigned; and 

(e) generating application shell code according to the 
operating system and the assigned names and control 
information. 

2. The method of claim 1, wherein said object state 
transition assigning comprises assigning a data condition 
and an action. 

3. The method of claim 2, wherein said action comprises 
assigning a transition method name with at least one of a call 
function, signal function, or spawn function to the transition 
method name, or assigning a nulHfication function according 
to the predefined application. 

4. The method of claim 1, wherein said generated appli- 
cation shell code is operable with other object-oriented 
systems via an object-oriented messaging system. 

5. The method of claim 4, further comprising: 
assigning a machine name to an assigned object name 

wherein said machine name identifies an object- 
oriented system connected to the object-oriented mes- 
saging system; and 
assigning a server name to the assigned machine name. 

6. The method of claim 5, wherein said server name 
identifies a server on the object-oriented system represented 
by said assigned machine name. 

7. The method of claim 5, wherein said generated appli- 
cation shell code is operable in the assigned server. 

8. An object-oriented system for automatically generating 
application shell code, said system comprising a processor 
with an operating system running thereon, at least one user 
interface device, memory and a display device, said system 
further comprising: 

(a) a graphical interface tool, operating in the operating 
system and displayed on the display device, for creat- 
ing object-oriented objects for use in a predefined 
application, wherein said graphical interface tool com- 
prises: 

(1) a first assigning means for assigning an object 
name; 
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(2) a second assigning means for assigning data names 
to the assigned object name according to predeter- 
mined requirements; 

(3) a third assigning means for assigning method names 
to the assigned object name according to predeter- 
mined requirements; and 

(4) a fourth assigning means for assigning control 
information to said assigned object name according 
to said predefined application, wherein said fourth 
assigning means of the graphical interface tool 
includes: 

(i) means for assigning at least one slate name, 
wherein each state name represents a distinct state 
of the object; and 

(ii) a means for assigning an object state transition, 
if more than one state is assigned; and 

(b) an automatic shell code generating tool, activated 
through said graphical interface tool and operating in 
the operating system, for generating application shell 
code according to the operating system and the 
assigned names and control information. 

9. The system of claim 8, wherein an assigned object state 
transition comprises a data condition and an action. 

10. The system of claim 9, wherein said action comprises 
at least one of a call function, signal function or spawn 
function of a transition method, or a nullification function. 

11. The system of claim 8, wherein said system is con- 
nected to other object-oriented systems via an object- 
oriented messaging system. 

12. The system of claim 11, wherein said graphical 
interface tool further comprises: 

a fifth assigning means for assigning a machine name to 
an assigned object name, wherein said machine name 
represents an object-oriented system connected to the 
object-oriented messaging system; and 

a sixth assigning means for assigning a server name to the 
assigned machine name. 

13. The system of claim 12, wherein said generated 
apphcation shell code is operable in the assigned server. 

14. The system of claim 12, wherein said assigned server 
name identifies a server on the object-oriented system rep- 
resented by said assigned machine name. 

IS- A computer-readable medium for automatically gen- 
erating application shell code, said computer-readable 
meditmi operable with a processor with an operating system 
mnning thereon, at least one user interface device, memory 
and a display device, said computer-readable medium fur- 
ther comprising: 
(a) a graphical interface tool, operable in the operating 
system and displayed on the display device, for creat- 
ing object-oriented objects for use in a predefined 
apphcation, wherein said graphical interface tool pro- 
gram comprises: 

(1) a first assigning means for assigning an object 
name; 

(2) a second assigning means for assigning data names 
to the assigned object name according to predeter- 
mined requirements; 

(3) a third assigning means for assigning method names 
to the assigned object name according to predeter- 
mined requirements; 

(4) a fourth assigning means for assigning control 
information to said assigned object name according 
to said predefined apphcation, wherein said fourth 
assigning means of the graphical user interface tool 
includes: 

(i) means for assigning at least one state name, 
wherein each state name represents a distinct state 
of the object; and 



02/17/2004, EAST Version: 1.4.1 



5,920,718 

21 22 

(ii) means for assigning an object state transition, if a graphical interface tool, operating in the operating 

more than one state is assigned; and system, displayed on the display device, for entering 

(b) an automatic shell code generating tool, activated object class information for an object-oriented object 

through said graphical interface tool and operable in the operating in a predefined application environment, 

operating system, for generating application shell code ^ wherein said object class information includes an 

according to the operating system and the assigned object class name, data name, method name, action 

names and control information. name, at least one state name, and at least one data 

16. The computer-readable medium of claim 15, wherein condition with a resulting transition; and 

andtn^'^clo?'''''^''' transition comprises a data condition ^^^^^^^^ ^j^^^ ^^^^ generating tool operating in the 

'\7' l^e'^mputer-readable medium of claim 16, wherein ^P''''^."^ u ' ^'"'''^^f application shell code 

said acUon comprises at least one of a call function, signal accordmg to the object class information entered in the 

function or spawn function of a transition method, or a ^J'^^ interface tool. 

nullification function. ^y^^^^ °^ ^^^^^ wherein a transition is 

18. The computer-readable medium of claim 15, wherein 15 assigned at least one of the following commands: 
said computer-readable medium located in an object- a call to an action name; 

oriented system is connectable to object-oriented systems a signal to an action name; 

via an object-oriented messaging system. a spawn to an action name; and 

19. The computer- readable medium of claim 18, wherein j- * j c j i- ^- 

.j u- ^ ■ . c . t £L ^x. • on a null according to predefined application environment, 

said graphical mterface tool further compnses: 20 ^ , <: i • -r^ u • i- l h 

^ ^ ^ 24. The system or claim 22, wherem the application shell 

a fifth assignmg means for assigning the name of an code generated by the automatic shell code generating tool 

object-oriented system connected to the object-oriented is compatible with the operating system, 

messaging system; and 25. The system of claim 22, wherein said system is 

a sixth assigning means for assigning a server name to the connected to other object-oriented systems via an object- 
assigned object-oriented system name. oriented messaging system. 

20. The computer- readable medium of claim 19, wherein 26. The system of claim 25, wherein said class informa- 
said server name identifies a server on the object-oriented lion for an object class name further includes an object- 
system represented by said assigned machine name. oriented system name of an object-oriented system con- 

21. The computer-readable medium of claim 19, wherein nected to the object-oriented messaging system and a server 
said generated application sheU code is operable in the name. 

assigned server. 27. The system of claim 26, wherein said server name is 

22. An object-oriented system for automatically general- assigned to the object-oriented system of the included 
ing application shell code, said system comprising a pro- object-oriented system name. 

cessor with an operating system running thereon, at least one 

user input device and a display device, further comprising: *:**** 
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